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ABSTRACT 


As  network  processors  have  advanced  in  speed  and  efficiency  they  have  also 
become  more  complex  in  both  hardware  and  software  configurations.  Intel’s  IXP1200  is 
one  of  these  new  network  processors  that  has  been  given  to  different  universities 
worldwide  to  conduct  research  with. 

The  objective  of  this  thesis  is  to  take  the  first  step  in  beginning  the  research  by 
providing  a  stable  system  that  can  provide  a  reliable  platform  for  further  research.  This 
thesis  introduces  the  fundamental  hardware  of  Intel’s  IXP1200  and  the  requirements  for 
installation  of  both  hardware  and  software  using  Windows  2000  and  Linux  7.2  as  the 
operating  system  in  support  for  the  IXP1200. 

This  thesis  will  provide  information  on  the  installation  of  hardware  and  software 
configuration  for  the  IXP1200  including  Intel’s  Software  Development  Kit  (SDK).  Upon 
completion,  this  platform  will  be  able  to  conduct  further  research  in  the  development  of 
the  IXP1200  network  processor.  It  provides  a  hardware  and  software  installation 
checklist  along  with  documentations  of  problems  encountered  and  recommendations  for 
their  resolution.  Included  is  an  example  using  preexisting  code  that  has  been  modified  to 
filter  packets  of  TCP  or  UDP  to  different  ports. 
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I.  BACKGROUND 


A.  THE  EVOLUTION  OF  NETWORK  PROCESSORS 

Up  until  the  late  1990’s,  most  network  routers  were  based  on  arehiteeture  similar 
to  a  personal  computer.  The  central  processing  unit  (CPU)  performed  the  basic  network 
layer  processing  tasks:  access  control  filtering,  forwarding  table  lookups,  and  routing 
updates.  The  central  processor  received  instructions  from  the  router’s  operating  system 
that  ran  in  random  access  memory  (RAM),  along  with  basic  instructions  that  were  stored 
in  read  only  memory  (ROM).  The  advantage  to  this  architecture  was  that  all  instructions 
were  stored  in  software;  therefore,  new  features  could  be  added  simply  by  upgrading  the 
systems  software,  much  like  in  a  PC.  Routers  could  also  be  designed  with  additional 
interfaces  that  supported  High  Speed  Serial  Interface  (HSSI),  without  having  to  touch  the 
basic  processor  architecture.  For  vendors  this  meant  that  their  basic  router  architecture 
could  support  a  variety  of  configurations  as  well  as  different  versions  of  the  same  basic 
operating  system.  Therefore,  vendors  were  able  to  quickly  develop  new  products  with  a 
reduced  time-to-market  and  make  routine  changes  at  a  low  cost  to  support  a  small 
segment  of  the  market.  [1,2] 

A  perfect  example  of  this  approach  is  the  Cisco  2500  product  line.  This  software- 
based  router  uses  a  central  processor  unit  to  perform  routing  instructions  based  on 
software  configurations  stored  in  nonvolatile  RAM.  The  Cisco  2500  series  is  available  in 
a  variety  of  specialized  hardware  configurations  depending  on  specific  application 
requirements,  such  as,  multiple  or  single  serial  ports,  multiple  or  single  attachment  unit 
interface  (AUI)  ports,  or  multiple  or  single  Token  Ring  ports.  On  the  software  side, 
dozens  of  different  software  versions  are  available  to  support  highly  specific  individual 
requirements.  [2] 

The  drawback  to  software-based  routers  is  their  limited  ability  of  scale  to  support 
the  demands  of  higher  bandwidth  and  additional  features.  For  example,  most  software- 
based  routers  currently  available  are  only  capable  of  supporting  wire-speed  throughput  of 
less  than  a  single  155  Mbps,  or  in  some  extreme  cases,  up  to  a  single  622  Mbps.  When 
these  same  routers  are  then  tasked  to  perform  complex  traffic  filtering,  policy  based 
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routing,  or  collection  of  traffic  statistics,  their  performance  suffers  and  their  maximum 
throughput  is  greatly  reduces.  [6] 

The  use  of  Application  Specific  Integrated  Circuits  (ASIC)  was  a  major  paradigm 
shift  for  hardware  manufacturers  in  the  production  of  network  devices.  Rather  than  using 
software-based  processing  and  improving  performance  by  increasing  the  speed  of  the 
central  processor,  hardware  manufacturers  discovered  they  could  achieve  tremendous 
performance  improvements  by  creating  specialized  chips.  These  ASIC  chips  are 
manufactured  with  embedded  instructions,  and  therefore,  perform  forwarding  decisions 
directly  in  hardware,  which  improves  the  overall  performance.  [11] 

While  ASIC-based  switching  has  allowed  for  a  new  generation  of  very  high-speed 
routers  and  switches,  there  is  a  downside  to  this  approach.  Once  instructions  or  logic  has 
been  embedded  into  silicon,  it  is  difficult  to  change  them  to  add  new  features  or  to 
improve  performance.  This  means  that  manufacturers  must  replace  the  ASIC  chips  to 
enable  new  functionality,  unlike  traditional  software-based  routers  and  switches  in  which 
new  features  can  be  added  by  simply  upgrading  the  operating  system.  Another  problem 
is  that  errors  in  the  ASIC  design  during  product  development  can  result  in  substantial 
time-to-market  delays  since  it  sometimes  takes  a  silicon  factory  a  month  or  more  to 
produce  a  new  set  of  ASIC  chips.  While  advanced  features,  such  as  complex  quality  of 
service  routing,  identification  of  upper  layer  flows,  gathering  of  accounting  information, 
or  access  control  filtering,  still  requires  traffic  to  be  processed  in  software  the 
performance  benefits  of  the  ASIC-based  architecture  is  reduced.  [12] 

The  demand  for  performance  has  given  rise  to  the  hybrid  configuration,  such  as, 
network  processors.  The  Intel’s  IXP1200  Network  Processor  family  is  an  example  of  the 
new  approach.  The  IXP1200  hardware  is  made  up  of  one  core  processor  the  StrongARM 
and  six  RISC  processors  or  Microengines  that  it  manages.  Since  both  the  StrongARM 
and  the  Microengines  are  software  driven  and  programmable  this  makes  the  development 
process  faster.  The  combination  of  specialized  machine  instructions  for  traffic  processing 
and  its’  ability  to  use  parallel  processing  with  the  Microengines  makes  it  possible  to  offer 
high  performance  along  with  versatility  for  change. 

The  IXP1200  contains  a  StrongARM  core  and  six  independent  32-bit  RISC  data 
engines  (Microengines),  as  well  as  SRAM,  SDRAM,  PCI  and  IX  bus  controllers.  The 
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operating  frequency  for  the  PCI  bus  is  up  to  166  MHz,  where  as,  the  IX  bus  operates 
between  166  and  232  MHz.  The  performance  of  the  processor  is  advertised  to  be  3 
million  packets  per  second  (3  Mpps),  which  is  1.5  Gbps  (3000000  *  64  bytes  *  8  bits). 
The  combination  of  six  ASIC-based  Microengines,  one  programmable  StrongARM 
processor,  both  SRAM  and  SDRAM,  and  a  dedicated  IX  bus  interconnecting  all  of  its 
components  has  produced  a  single  network-processing  chip  that  is  both  programmable 
and  very  efficient.  [11] 

Synchronous  Random  Access  Memory  (SRAM)  is  a  type  of  RAM  that  holds  its 
data  without  external  refresh  for  as  long  as  power  is  supplied  to  the  circuit.  This  is 
contrasted  to  dynamic  RAM  (DRAM),  which  must  be  refreshed  numerous  times  per 
second  in  order  to  hold  its  data  contents.  SRAMs  are  used  for  specific  applications 
within  the  PC,  where  their  strengths  outweigh  their  weaknesses  compared  to  DRAM. 
SDRAM  incorporates  new  features  that  allow  it  to  keep  pace  with  bus  speeds  as  high  as 
100  MHz.  It  does  this  primarily  by  allowing  two  sets  of  memory  addresses  to  be  opened 
simultaneously.  Data  can  then  be  retrieved  alternately  from  each  set,  eliminating  the 
delays  that  normally  occur  when  one  bank  of  addresses  must  be  shut  down  and  another 
prepared  for  reading  during  each  request.  [19] 

Network  Processors  are  designed  to  take  advantage  of  the  inherent  parallelism  in 
the  packet  processing  programs.  Most  of  them  provide  additional/replicated  resources  on 
the  chip  in  order  for  packets  to  be  processed  in  parallel.  For  example,  the  Intel  IXP1200 
network  processor  has  six  Microengines  on  the  chip.  These  are  simple  RISC  processors 
that  run  independently  and  can  accelerate  functions  like  hashing,  calculations,  lookups, 
and  so  on. 

Network  processors  have  been  used  as  an  attractive  alternative  to  pure  PC-based 
routers.  Even  though  their  architectures  can  be  used  to  support  network  monitoring,  a 
newer  much  more  performance-oriented  architecture  is  needed. 

B,  THE  INTEL  IXP1200  NETWORK  PROCESSOR 

This  section  will  briefly  introduce  the  architecture  of  the  IXP1200,  derived  from 
the  Intel  IXP1200  Network  Processor  Family  Hardware  Reference  Manual.  An 
exhaustive  hardware  specification  can  be  found  at  Intel’s  website. 
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http://www.intel.com/design/network/products/npfamilv/index.htm.  Figure  1  is  provided 
as  a  reference  while  discussing  IXP1200  configuration. 


’  Other  names  and  brands  may  be  claimed  as  the  property  of  others. 
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Figure  1 .  Intel  IXP1200  Diagram  (From  Ref  11) 


1,  Memory 

The  IXP1200  has  three  types  of  memory  resources  available  to  the  programmer: 
SRAM,  SDRAM,  and  Scratchpad  RAM.  These  memories  vary  in  latency,  size,  and 
bandwidth.  SDRAM  memory  is  typically  used  for  storage  of  packet  data  and  very  large 
tables;  whereas,  SRAM  memory  is  used  for  table  lookups  where  low  latency  is  very 
important.  Scratchpad  RAM,  being  internal  to  the  IXP1200,  is  smaller  but  with  very  low 
latency  and  is  most  often  used  for  inter-process  communication,  and  shared  semaphores 
or  counters  to  enable  Microengines  to  share  resources.  [11] 
a.  SDRAM 

The  SDRAM  unit  is  for  interfacing  to  external  SDRAM  via  a  64bit  x 
116Mhz  bus.  It  shares  an  intelligent  memory  interface  that  can  be  accessed  by  the 
StrongARM,  Microengines,  and  other  devices  on  the  PCI  bus.  It  is  a  flexible  interface  to 
standard,  low-cost  SDRAMs  that  are  capable  of  moving  blocks  of  data  between  the 
SDRAM  and  the  Microengines  by  using  the  IX  Bus  Unit,  or  devices  on  the  PCI  bus.  [3]. 
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b.  SRAM 

The  SRAM  unit  interfaces  to  external  SRAM  via  a  32bit  x  1 16Mhz  bus.  It 
shares  an  intelligent  memory  interface  accessible  by  the  StrongARM  and  the 
Microengines.  It  provides  a  flexible  interface  to  standard  pipeline  and  flow-through. 
SRAMs  are  capable  of  moving  blocks  of  data  between  the  SRAM  and  the  Microengines 
by  using  the  IX  Bus.  [4]. 

2,  StrongARM  Core  Processor 

The  core  processor  for  the  IXPI200  is  a  32-bit  StrongARM  RISC  processor.  It 
may  be  used  in  two  different  ways  depending  on  the  application  and  host  CPU  that  is 
available.  In  configurations  where  there  is  no  host  processor  or  the  host  processor  is 
limited,  the  StrongARM  would  act  as  the  main  processor  running  a  Real  Time  Operating 
System,  performing  system  maintenance  functions,  as  well  as,  running  as  the  core 
processor.  Alternately,  the  StrongARM  can  leave  the  system  maintenance  processing  to 
the  host  processor  of  the  CPU,  acting  as  only  the  exception  processor,  performing  higher- 
layer  processes  for  the  Microengines.  The  latter  is  the  configuration  that  is  used  for  this 
paper.  The  StrongARM  runs  a  mini-kernel  and  executes  routing  protocols,  while  the 
Microengines  do  the  fast-path  packet  processing.  [11] 

The  operating  system  functions  of  the  StrongARM  boot  from  Flash  memory  over 
the  SRAM  interface.  The  StrongARM  can  then  load  the  Microengines  with  their  own 
programs.  The  StrongARM  communicates  with  the  Microengines  via  shared  registers 
and  a  shared  on-chip  Scratchpad  RAM.  It  also  has  the  ability  to  enable  or  disable  any  of 
the  Microengines  or  any  of  the  Microengine  threads.  The  StrongARM  can  make  changes 
to  the  Microengine  instruction  store  at  any  time  by  disabling  the  Microengine,  and 
writing  to  their  instruction  store  and  then  restarting  that  Microengine.  The  granularity  of 
the  StrongARM ’s  ability  to  manage  the  Microengine  reaches  down  to  the  individual 
threads  running  on  the  Microengines.  [11] 

3,  Microengines 

The  six  Microengines  operating  at  232Mhz  are  compact  and  efficient  RISC 
engines  that  are  used  for  any  function  requiring  high-speed  packet  inspection,  data 
manipulation,  and  data  transfer.  These  32-bit  engines,  with  a  5-stage  execution  pipeline 
and  a  large  (256)  register  set,  are  fully  programmable.  The  Microengine  is  designed  in 
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such  a  way  to  provide  multi-threaded  operations  enabling  eaeh  Mieroengine  the  ability  to 
run  up  to  four  threads  at  the  same  time.  The  Mieroengine  runs  on  a  lower  language  of 
assemble  eode.  It  is  within  the  Microengines  that  the  speed  of  proeessing  is  achieved. 
The  StrongARM  is  mueh  like  the  manager  in  a  groeery  store  with  the  cashiers  being  the 
Mieroengines.  The  cashiers  handle  the  majority  of  the  daily  tasks  in  the  most  efficient 
way  possible.  It  is  the  StrongARM  or  the  manager  that  handles  eomplex  or  unexpeeted 
tasks  and  leaves  the  Mieroengines  free  to  take  eare  of  other  tasks.  [11]. 

4,  IX  Bus 

The  IX  Bus  is  the  main  interfaee  for  reeeiving  and  transmitting  data  with  external 
devices,  such  as,  MAC  devices  and  other  IXP  1200s.  It  is  64  bits  wide  and  runs  up  to 
I04MHz  allowing  for  a  maximum  throughput  of  6.6Gbps.  The  Mieroengines  ean 
direetly  interact  with  the  IX  bus  through  an  IX  Bus  Unit;  so  a  thread  running  on  a 
Mieroengine  may  reeeive  or  transmit  data  on  any  port  without  StrongARM  intervention. 
This  interaetion  is  performed  via  Transmit  and  Reeeive  FIFO  queues,  whieh  are  eircular 
buffers  that  allow  data  transfers  direetly  to/from  SDRAM.  For  the  Mieroengines  to 
internet  with  peripherals,  they  need  to  query  or  write  to  eontrol  status  registers. 

5,  Fast  Bus  Interface  (FBI) 

The  FBI  unit  eontains  several  parts  that  are  IK  of  memory  of  32  bit  words  on  the 
scratehpad,  a  hash  unit  and  the  interfaee  to  the  IX  bus  which  connects  the  network 
interfaee  eard  to  the  IXP  1 200.  The  memory  is  divided  into  two  parts  the  Reeeive 
memory  and  the  Transmit  memory.  Both  reeeive  and  Transmit  memory  aet  as  a  buff 
between  the  host  eomputer  and  the  IXPI200.  [15] 

6,  Host  Computer 

The  IXP  1 200  is  eontained  on  a  PCI  eard  that  is  mounted  into  a  host  eomputer. 
The  IXPI200  card  requires  that  the  host  eomputer  use  Linux  7.2  as  its  operating  system 
to  enable  the  IXP  1200  card  and  the  host  eomputer  to  eommunieate  with  eaeh  other.  This 
eommunieation  is  done  through  the  PCI  bus  which  the  IXPI200  card  is  attached  too. 
When  the  IXP  1 200  eard  is  in  plaee,  the  host  eomputer  provides  power  to  run  the  eard, 
hard  disk  spaee  for  storage  of  programs  or  operating  instruetions.  The  PCI  interfaee 
provides  eommunieation  between  the  host  proeessor  and  the  IXPI200.  With  the 
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IXP1200  card  installed  it  operates  as  an  extinetion  of  the  host  eomputer  so  all 
oommunieation  to  and  from  the  IXP1200  is  done  through  the  host  eomputer.  [11] 

C.  SUMMARY 

Network  proeessors  started  as  a  eentral  proeessing  unit  that  used  RAM  and  ROM 
to  store  its  operating  system  and  routing  tables  to  maintain  eonneetions  to  the  networks. 
This  very  simple  system  has  evolved  along  with  the  networks  that  we  have  today  to  a 
very  ridged  system  of  removing  RAM  and  ROM  to  designing  the  programming  into 
hardware  during  the  manufaeturing  proeess  of  the  network  proeessors.  Along  with  using 
multiple  proeessors  that  are  programmable  to  aeeomplish  a  single  task  in  parallel  while 
enabling  both  speed  of  proeessing  and  programming  flexibility. 

Intel  developed  the  IXP1200  network  proeessor  board  that  eonsists  of  multiple 
programmable  proeessors.  It  is  made  up  of  two  buses,  the  PCI  bus  and  the  IX  bus.  The 
PCI  bus  is  used  for  eommunieations  between  the  host  eomputer  and  the  IXPI200  eard. 
While  the  IX  bus  is  the  bus  system  on  the  eard  providing  the  eommunieation  link 
between  the  eomponents  on  the  eard.  The  eard  is  made  up  of  one  master  proeessor,  the 
StrongARM,  whieh  supports  six  proeessors  the  Mieroengines  that  run  independently.  All 
are  programmable  being  able  to  provide  both  inereased  network  proeessing  speed  and  the 
programmability  for  ehange. 

The  next  ehapter  will  eover  the  funetionality  of  the  IXP1200  software  and  its 
installation. 
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II.  INTEL’S  SOFTWARE  DEVELOPMENT  KIT  AND 

INSTALLATION 

Intel’s  Software  Development  Kit  (SDK),  Version  2.0,  is  made  up  of  a  C  compiler 
Cygwin,  which  is  a  command  line  interface;  and  VMware,  which  is  a  virtual  machine  that 
runs  on  Windows  to  support  the  Linux  operating  system.  More  information  on  VMware 
can  be  found  at  http://www.vmware.com/products/  or  information  on  Cygwin  can  be 
found  at  http://cygwin.com/.  Within  the  SDK,  Intel  provided  a  GUI  called  The 
Developer’s  Workbench  that  provides  help  with  programming  and  with  the  operation  of 
the  IXP1200.  These  tools  are  combined  to  provide  complete  resources  needed  for 
programming,  including  a  resource  of  libraries  for  code  reuse,  modification,  and  as  a 
development  environment  to  assist  the  programmer. 

The  Developer’s  Workbench  is  a  key  component  of  the  SDK  that  features  a  GUI 
based  simulator  for  the  Microengines  and  hardware  of  the  IXP1200  network  processor. 
The  simulator  is  used  as  a  test  bed  for  the  Microengine  code  as  it  is  developed.  Within 
the  Workbench  there  are  many  pre-developed  Active  Computing  Elements  (ACEs) 
provided.  ACEs  are  similar  to  a  macro  or  fragments  of  code  that  have  already  been 
developed  and  tested  for  functionality  and  efficiency.  These  ACEs  may  be  combined  to 
produce  code  to  be  run  on  the  IXP1200.  ACEs  that  are  written  in  C  or  C++  can  be  run 
directly  on  the  StrongARM.  The  ACEs  must  be  in  the  appropriate  assembler  language  in 
order  to  run  on  the  Microengines.  This  is  the  main  benefit  of  the  Workbench,  in  that  it  is 
the  only  available  tool  to  accomplish  the  task  of  compiling  code  for  the  Microengines. 
The  process  to  produce  code  for  the  Microengines  is  to  take  ACEs  that  are  already 
written  from  the  Development  Workbench  and  combine  them  into  a  single  functioning 
piece  of  code  that  then  is  compiled  using  Workbench  into  a  list  file  that  will  be  run  on  the 
targeted  Microengine. 

The  Workbench  is  capable  of  debugging  code  using  the  target  hardware  or 
simulating  a  packet  flow  for  testing  code.  The  debugger  can  be  used  to  debug  the  code  to 
be  run  on  the  Microengines.  Within  the  debug  mode  there  is  the  option  of  setting 
breakpoints,  single  step  commands,  and  jumping  over  a  function.  Other  features  of  the 
Developer’s  Workbench  are  access  to  a  command  line  window,  performance  statistics. 
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facilities  to  save  and  restore  simulation  session,  memory  modify  history,  data  watch 
window,  and  thread  history  window. 


Figure  2.  IXP1200  Workbench  GUI  (Ref  18) 


Figure  2  shows  a  typical  window  of  the  Developer’s  GUI  Workbench.  It  looks 
and  acts  much  like  Microsoft’s  Visual  Studio,  but  there  are  many  differences  because  the 
target  hardware  configuration  includes  one  core  processor  and  six  supporting  processors. 
Below  are  some  of  the  more  important  parts  of  the  functions  of  Workbench  that  will  be 
described  in  greater  detail 
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A, 


BUILD  SETTINGS 


Figures.  Project  Workspace 


Figure  3  shows  the  file  manager  in  Workbench.  The  source  files  for  both  the 
assembler  and  the  compiler  are  listed  alphabetically  in  their  own  file.  Source  files  can  be 
added  by  clicking  on  the  project  bottom  or  by  providing  an  include  statement  similar  to 
C++.  Macro  are  listed  in  two  files  by  the  name  of  the  macro  and  by  the  name  for  easy 
access.  One  of  the  benefits  of  Workbench  is  that  it  provides  this  file  of  commonly  used 
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macros  that  can  be  added  to  the  projeet  with  minimal  effort. 


Figure  4.  General  Build  Settings 


After  assembly  code  is  written,  additional  settings  must  be  configured  to  build 
and  run  the  program.  In  Figure  4  there  is  an  example  of  the  window  from  the 
development  workbeneh  for  the  general  build  settings.  It  is  here  that  the  compiler  is  told 
were  to  look  for  the  files  that  are  needed  to  build  and  eompile  the  eode  for  the  projeet. 
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Figures.  Build  Settings  Assembler 


Within  the  window  displayed  in  the  Figure  5  are  the  options  to  assign  the  root  file 
and  the  target  list  file.  The  Root  file  is  the  much  like  the  main  in  C++  that  the  project 
will  run  from  many  times  it  is  a  dispatch  loop.  The  target  list  file  is  the  place  that  the 
compiler  will  send  the  compiled  code  to  be  run  on  the  Microengines. 


13 


Figure  6.  Build  Setting  Linker 


Figure  6  eontains  the  deeision  as  to  whieh  Mieroengine  will  run  what  list  file. 
The  list  file  is  is  shown  in  the  Linker  tab  (Figure  6).  This  is  how  to  tells  the  eompiler, 
whieh  Miero engines  will  run  what  list  file  for  the  program.  It  is  important  to  eonsider 
while  assigning  the  list  files  to  the  Microengines  that  you  manage  resources  like  memory 
and  Microengines  to  reduce  bottle  neck  in  the  project.  The  simulator  is  a  very  good  tool 
found  within  the  debugger  to  find  and  reduce  bottlenecks. 
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B,  DEBUGGING  CODE 

The  debugging  seetion  of  the  Development  Workbench  is  a  very  useful  tool.  The 
debug  section  provides  tool  for  tracking  history  of  the  program  as  it  runs.  This  history 
can  be  tracked  all  the  way  down  to  each  thread  that  is  run  at  the  same  time.  Other 
functions  of  the  debug  are  command  line  inter  face  and  a  data  watch  to  track  variables. 
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Figure  7.  Thread  View 


Figure  7  is  an  example  of  the  thread  view  in  the  debug  mode. 

The  Thread  View  window  provides  a  graphic  view  of  the  six  Microengines  and 
the  four  threads  that  can  be  run  on  each  Microengine. 


Info  View  provides  access  to  documentation  on  the  Workbench  components,  such 
as,  the  Development  Tools  User’s  Guide  and  the  Programmer’s  Reference  Manual. 


Figure  8.  Thread  and  Queue  History  Window 
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Figure  8  is  the  Tread  and  Queue  History  window  that  provides  a  view  of  the 
Microengines  executing  code,  making  it  possible  to  quickly  locate  performance 
bottlenecks.  The  threads  and  queues  are  displayed  on  a  timeline  that  represents  the 
number  of  cycles  executed.  The  line  segments  on  the  timeline  change  color  depending 
on  whether  an  instruction  is  executing,  stalled  (waiting  on  resources  to  complete  a  task), 
aborted,  or  idle  (waiting  for  a  task  to  be  assigned). 


Figure  9.  Command  Line 

Figure  9  shows  the  command  line  interface.  It  has  two  functions,  one  for 
simulation  mode  and  the  other  for  hardware  mode.  In  simulation  mode  the  command  is 
passed  to  the  simulator,  which  in  turn  sends  the  command  and  the  response  back  to  the 
command  line  window.  In  hardware  mode  the  command  line  provides  an  alternate  way 
to  access  the  hardware.  Some  of  the  commands  that  it  supports  are  C  interpreted 
functions,  script  files  and  conditional  directives. 


Figure  10.  Data  Watch 


Data  Watch  is  useful  in  tracking  the  value  of  variables  (Figure  10).  To  view  a 
particular  variable,  enter  the  name  of  the  variable  in  the  Name  block  of  the  data  watch 
window.  Data  Watch  will  update  the  variable  when  the  Microengine  or  thread  execution 
has  stopped. 
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The  network  simulator  ean  be  used  to  run  new  eode  to  eompare  run  times.  One  of 
the  niee  things  about  the  simulator  is  that  it  will  produce  line  graphs  of  different 
simulations  for  comparison.  This  should  prove  very  useful  in  a  multi-thread  environment 
when  it  is  necessary  to  find  code  bottlenecks.  It  also  has  a  very  extensive  library  of  tested 
code  that  can  support  code  reuse.  The  debug  section  of  the  SDK  can  separate  each  thread 
of  the  program,  both  graphically  and  as  it  steps  through  the  code. 

C.  INSTALLATION  OF  IXP1200  CARD  AND  SOFTWARE 

The  host  machine  requires  a  modified  version  of  Linux  7.2  operating  system  in 
order  to  run  and  communicate  with  the  StrongARM.  The  StrongARM  uses  a  very 
limited  version  of  the  Linux  operating  system.  The  resources  available  to  the  IXP1200 
are  very  limited.  For  this  reason,  the  StrongARM  uses  the  host  computer’s  hard  drive  to 
store  its  files.  The  Linux  C  compiler  is  used  to  compile  code  to  be  run  on  the 
StrongARM.  Linux,  or  Cygwin,  if  a  version  of  Windows  operating  system  is  running  on 
the  host,  is  used  to  move  files  from  the  host  machine’s  directory  to  where  the 
StrongARM  can  read  them. 

For  the  installation  of  the  IXP1200  card  and  software  needed  to  support  the  card 
refer  to  Appendix  B.  Appendix  B  provides  a  complete  checklist  for  installing  the  SDK 
Windows  operating  system  and  Linux  7.2  with  Cygwin. 

D,  SUMMARY 

Intel’s  Software  Development  Kit  (SDK)  contains  a  GUI  known  as  the 
Developer’s  Workbench.  This  Developer’s  Workbench  is  the  key  component  of  SDK 
which  features  a  GUI  based  simulator  for  the  Microengines  and  the  hardware  for  the 
IXP1200  network  processor.  Its  main  function  is  to  test  the  programs  it  develops  for  the 
Microengines  within  which  are  many  pre-developed  Active  Computing  Elements 
(ACEs).  These  already  proven  and  tested  bits  of  codes  or  macros  are  combined  to 
produce  code  to  run  on  the  IXP1200.  In  order  for  the  Ace  to  run  on  the  Microengine  the 
Workbench  modifies  the  ACE  to  an  assembler  level. 

The  Workbench  is  able  to  debug  code  using  the  target  hardware  and  simulating 
packet  flow  for  the  code  being  tested.  Within  this  mode  there  are  several  options,  such 
as,  setting  breakpoints,  single  step  commands,  and  jumping  over  functions.  Other 
important  features  of  the  Developer’s  Workbench,  such  as,  command  line  window. 
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performance  statistics,  save  and  restore  simulation,  memory  modification,  data  watch 
window,  and  thread  history  window.  This  development  tool  is  set  up  in  such  a  way  to 
take  a  complicated  situation  and  making  it  simpler  with  the  reuse  of  code. 
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III.  PROGRAMMING  PACKET  FILTER  ON  IXP1200 


Programming  the  IXP1200  is  substantially  different  then  a  typieal  sequential  line 
program  that  has  only  one  proeessor  with  which  to  deal  with  when  writing  code.  The 
IXP1200  is  designed  to  be  programmable  and  multi-threaded,  thus  able  to  run  tasks  in 
parallel  Additionally,  it  can  run  independent  from  the  host  computer’s  processing  unit. 
Being  programmable  allows  great  flexibility  to  change  or  modify  operation  through 
programming.  Multi-threading  provides  the  possibility  of  great  processing  speed.  To 
program  in  this  kind  of  an  environment  is  very  complex  due  to  potential  memory 
conflicts,  since  more  then  one  processor  uses  the  same  memory.  Getting  the  different 
processors  to  work  together  to  complete  tasks  efficiently  is  also  a  challenging  task.  Intel 
has  reduced  the  complexity  of  coding  in  this  environment  with  the  use  of  Active 
Computing  Elements  (ACEs). 

ACEs  are  small  chucks  of  code  that  have  been  perfected  to  be  run  on  the 
IXP1200.  They  can  be  used  as  building  blocks  which  are  assembled  to  complete  more 
complex  operations.  These  ACEs  have  already  been  tested  and  perfected  for  efficiency 
and  reliability.  This  makes  it  possible  to  assemble  ACEs  with  minimal  effort  and 
resulting  in  a  reliable  and  efficient  product  following  the  paradigm  of  code-reuse. 

There  are  two  categories  of  ACEs:  ACEs  and  MicroACEs.  ACEs  are  run  on  the 
StrongARM,  and  solely  written  in  C  and  C++,  while  MicroACEs  are  simply  an  ACE  that 
has  been  compiled  to  run  only  on  the  IXP1200  Microengines.  The  MicroACEs  and 
Microengines  form  the  fastest  processing  path.  As  noted  above,  they’re  assembled 
together  or  linked  together  to  complete  tasks,  in  this  way  they  work  as  a  team.  Each  one 
has  its  own  function  to  complete  then  calls  the  next  ACE  which  calls  the  next  ACE  until 
the  whole  process  is  complete.  Below  is  more  detail  concerning  the  process  of  creating 
code  and  using  ACEs. 

A,  DESIGNING  A  PACKET  FILTER  APPLICATION 

In  today’s  Internet  the  speed  of  handling  traffic  is  paramount  to  being  efficient 
because  of  the  increased  amount  of  traffic  that  is  present  on  it.  In  order  to  filter  packets 
to  or  from  the  Internet  all  packets  have  to  go  through  the  filter.  If  the  filtering  process  is 
slower  than  the  routing  process,  the  filter  will  become  a  bottleneck.  The  IXP1200  has 
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two  main  components  on  which  code  is  run,  the  StrongARM  and  the  Mieroengines.  Both 
have  to  be  eonsidered  when  producing  code.  Both  support  the  use  of  ACEs  in  the 
process  of  developing  code  for  the  IXP1200. 

ACEs  are  the  building  blocks  that  make  up  the  eode  that  runs  on  the  IXP1200 
eard.  In  terms  of  functions  there  are  three  types  of  ACEs  running  on  the  StrongARM; 
User  ACEs,  Eibrary  ACEs,  and  System  ACEs.  User  ACEs  provide  the  user  interfaee  to 
the  system.  Eibrary  ACEs  are  those  provided  by  the  Workbench  or  Intel  to  produce 
common  functions  for  use  within  the  eode.  System  ACEs  implement  network  interfaees, 
protoeol,  and  algorithms.  Control  ACEs,  a  subeategory  of  System  ACEs,  produce  routing 
tables. 

When  dealing  with  packets,  an  ACE  does  three  things:  it  classifies  the  packet,  aets 
on  the  packet  or  disposes  of  the  paeket.  An  ACE  also  communicates  with  other  ACEs 
through  queries.  These  queries  allow  eaeh  ACE  to  monitor  the  status  of  such  things  as 
traffic,  completion  of  tasks,  and  memory  management. 

ACEs  encourage  modularity,  redueing  the  complexity  of  eode  verifieation  and 
validation,  beeause  an  applieation  can  be  implemented  by  chaining  several  existing  ACEs 
together  to  aehieve  the  desired  funetionality.  If  the  ACEs  are  already  debugged  and 
tested,  a  programmer  can  be  eonfident  that  by  using  these  ACEs  the  eode  that  is  produeed 
will  be  both  efficient  and  need  limited  debugging.  Sueh  modularity  is  possible  due  to  the 
Library  ACEs,  whieh  by  using  them  reduces  the  duration  of  the  coding  process.  Another 
benefit  is  that  ACEs  can  be  reused  in  many  applieations  without  having  to  be  recreated 
from  scrateh.  An  example  ean  be  seen  in  the  packet  filter  in  Appendix  A  whieh  was 
ereated  with  Library  ACEs  with  little  difficulty. 

When  designing  an  applieation  to  run  on  the  IXP1200  it  is  useful  to  divide  it  up  so 
it  will  be  manageable.  One  suggestion  is  to  design  the  different  functions  and  ACEs 
along  with  establishing  the  packet  flow  for  the  applieation.  Produeing  an  integrated 
applieation  involves  the  following  general  steps. 

Eirst,  define  the  functions  and  packet  flows  of  the  ACEs  that  run  on  the 
StrongARM  and  MicroACEs  that  run  on  the  Mieroengines.  This  must  be  accomplished 
for  each  Microengine  used  by  the  application.  Next,  the  programmer  must  determine 
whieh  ACEs  will  be  executed  by  the  Mieroengines  and  whieh  will  be  executed  by  the 
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StrongARM,  running  as  the  core  processor.  At  this  point  a  dispatch  loop  is  written  to 
implement  the  packet  flow  within  the  application.  Microblocks  are  simply  a  group  of 
ACEs  put  together  to  complete  a  task  or  function. 

Dispatch  loop  configures  the  group  of  functions  in  a  Microblock  into  a  processing 
pipeline.  The  dispatch  loop  along  with  code  in  a  Microblock  is  compiled  into  a  single 
“.uof’  file  that  will  be  downloaded  to  the  Microengines  to  be  run  as  an  application.  It 
then  decides  how  many  Microengines  to  load  with  each  image  of  the  code.  This  depends 
on  the  port  configuration  of  the  application.  Each  Microengine  is  able  to  run  four  threads 
and  each  10/100  Mbps  port  requires  one  thread.  Thus,  each  Microengine  can  run  four 
standard  or  fast  Ethernet  ports.  However,  a  gigabit  port  requires  eight  threads,  which 
means  two  Microengines  are  required.  All  of  this  is  done  in  the  Workbench  that  can  then 
provide  the  means  to  test  the  program  for  efficiency.  Care  must  be  taken  to  ensure  that 
overhead  operations  are  limited  to  reduce  bottlenecks  caused  by  the  sharing  of  resources. 
Eor  this  reason  it  is  best  to  limit  the  use  of  dividing  Microblocks  among  different 
Microengines.  [18] 

B,  MPACKETS  AND  MEDIA  ACCESS  CONTROLLER 

The  IXP1200  network  processor  card  must  break  down  all  input  packets  into  64- 
byte  Mpackets  in  order  to  be  used  by  the  IX  bus,  which  is  the  primary  data  path  for  the 
IXPI200. 

The  Media  Access  Controller  (MAC)  segments  the  original  packets  into  Mpackets 
and  reassembles  them  upon  completion  of  the  filter  processing.  The  first  MPacket  will 
have  the  label.  Start  of  Packet  (SOP),  prep  ended  while  the  last  will  have  the  label.  End  of 
Packet  (EOP),  appended.  An  original  packet  of  length  64  bytes  or  less  will  have  both 
labels  affixed  and  be  seen  by  the  Microengines  as  a  whole  packet.  Original  packets 
longer  than  128  bytes  will  be  fragmented  such  that  the  first  and  last  MPackets  generated 
will  have  the  appropriate  label  affixed,  but  interior  MPackets  are  unlabeled. 

The  MAC  puts  the  Mpacket  on  the  IX  bus;  from  there  it  goes  to  the  Past  Bus 
interface  (PBI)  to  feed  the  Microengine.  The  Microengine  then  must  reassemble  the 
original  packet  from  the  Mpackets  using  a  buffer  in  the  SDRAM.  The  buffer  holds 
sequential  Mpackets  until  an  Mpacket  is  received  with  the  label  EOP  at  which  time  the 
restored  packet  is  complete  and  can  be  processed. 
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Figure  1 1 .  Flow  chart  for  Mpackets  (From  Ref  1) 

C.  PROCESSING  PACKETS 

The  processing  of  packets  can  include  several  Microblocks  and,  depending  on 
how  they  are  assigned  to  parts  of  the  IXP1200  network  processor,  can  have  a  dramatic 
effect  on  system  performance.  When  assigning  Microblocks  to  Microengines,  a  single 
Microblock  should  be  processed  on  a  single  Microengine,  due  to  the  added  cost  of  inter¬ 
process  communication  if  the  Microblock  crosses  Microengines.  Further,  up  to  four 
Microblocks  can  be  processed  simultaneously  on  a  single  Microengine.  More  than  four 
Microblocks  on  a  single  Microengine  results  in  extra  overhead,  as  the  various  blocks 
must  be  scheduled  to  run  according  to  the  limitation  of  four  concurrent  threads  that  are 
possible  to  be  run  on  each  Microengine.  Running  packets  of  different  sizes  on  the  same 
Microengine  also  increases  overhead  cost  as  the  Microengine  has  to  assemble  the 
Mpacket  packets  from  the  IX  bus.  It  is  best  to  assign  differing  packet  types  to  separate 
Microengines  since  they  must  be  processed  differently.  This  helps  to  limit  the  overhead 
involved  in  the  process.  [5] 

1,  Dispatch  Loops 

Dispatch  loops  are  used  to  separate  different  types  of  packets  and  control  the  flow 
of  packets.  Below  is  pseudo  code  representing  a  dispatch  loop. 
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WMe(Tme){ 

Get  next  packet  from  input  device (s); 

Invoke  ingress  Microblock; 

If  (return  code  ^False){ 

Drop  the  packet; 

}  else  if  (return  code  ^  True)  { 

Send  packet  to  ingress  core  component; 

}  else  {/*IP  packet*/ 

Invoke  IP  Microblock; 

I£(retum  code  ^False){ 

Drop  packet; 

}  else  if  (return  code  ^TrueD  { 

Send  packet  to  IP  core  component; 

}  else  { 

Send  packet  to  egress  Mcroblock; 

} 

} 

This  dispatch  loop  is  an  endless  loop  that  gets  the  packet  from  the  input  device 
(IX  bus).  It  starts  a  Microblock  that  checks  the  paeket  to  see  whieh  of  three  options  is 
appropriate:  1)  drop  the  packet,  2)  send  it  to  a  Microbloek  to  be  cheeked  again,  or  3) 
send  it  to  another  Microblock  to  be  proeessed.  The  seeond  ehoice  of  the  loop  ealls  an  IP 
Mierobloek  and  then  further  divides  the  proeessing,  based  on  the  result  of  the  IP 
Mieroblock,  into  three  more  additional  ehoiees:  1)  drop  the  paeket,  2)  send  it  to  a  core 
eomponent,  or  3)  send  it  to  an  egress  Mierobloek  to  be  proeessed. 

The  ingress  souree  block  gets  a  packet  from  a  port  and  reeords  the  input  port  in  a 
global  register  using  a  dispateh  loop  maero,  and  then  passes  the  packet  to  the  Layer  3 
Forwarder  Block. 

The  Layer  3  Forwarder  Block  checks  whether  the  packet  is  an  IP  packet,  an  ARP 
packet,  or  another  type  of  paeket.  For  every  IP  paeket,  the  Layer  3  Forwarder  will 
validate  the  packet.  If  the  packet  is  invalid,  it  will  be  dropped.  If  the  packet  is  valid  but 
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has  options  in  the  header,  is  fragmented,  or  is  multi-cast  it  will  be  sent  to  the  StrongARM 
ACE  component  of  the  Layer  3  Forwarder.  This  communication  mechanism  is  handled 
via  the  dispatch  loop  and  the  resource  manager.  Otherwise,  the  next-hop  MAC  address 
and  output  port  number  will  be  obtained  from  the  forwarding  table.  The  output  port 
number  is  recorded  in  a  global  register  using  a  dispatch  loop  macro.  [14] 

If  the  packet  is  not  sent  to  the  StrongARM,  then  the  dispatch  loop  will  queue  the 
packet  for  egress.  There  is  one  queue  per  port  and  the  dispatch  loop  will  look  at  the 
output  port  to  determine  which  queue  to  use.  The  egress  Microblock  removes  the  next 
packet  from  the  queue  and  sends  it  out  over  the  appropriate  port.  [14] 

If  a  packet  is  sent  to  the  StrongARM,  the  L3  StrongARM  ACE  component 
processes  the  packet  and  sends  it  to  the  egress  output  interface  ACE  using  the  bound 
target.  The  egress  ACE  then  sends  it  down  to  the  egress  Microblock  using  a  resource 
manager  call.  Alternatively,  the  L3  ACE  may  choose  to  send  the  packet  back  down  to 
the  L3  Microblock  using  the  resource  manager  based  on  the  criteria  set. 

D,  FILTERING  TCP  AND  UDP 

Appendix  A  contains  the  packet  filter  for  TCP  and  UDP  packets  that  will  be 
discussed  below.  This  packet  fdtering  application  has  three  dispatch  loops:  Global 
Registers,  Macros,  and  Application.  The  Global  Registers  dispatch  loop  supports  each 
Microblock  that  sets  and  accesses  the  dl  buffer-handle  and  dl  next  block  global 
registers.  The  Macros  dispatch  loop  provides  predefined  macros  that  can  be  used  to 
perform  the  following  actions:  access  cached  variables,  assign  input  and  output  ports  for 
the  buffered  packet,  dispatch  a  buffered  packet  by  dropping  the  packet  or  sending  the 
packet  to  a  different  Microblock  group,  or  follow  the  transfer  of  packets  between  the 
Microblock  and  the  core  component  of  a  MicroACE.  The  Application  dispatch  loop 
defines  constants  and  declares  registers  to  be  used  within  the  dispatch  loop.  TCP/UDP 
filtering  can  be  implemented  by  modifying  a  function  with  in  the  Count  program,  an 
example  program  provided  by  the  IXP1200  SDK.  Appendix  A  shows  the  modified 
function  that  can  be  used  to  implement  the  TCP  and  UDP  packet.  The  original  Count 
function  can  be  found  in  the  Intel  Internet  Exchange  Architecture  Software  Development 
Kit  CD  1.  The  path  for  this  project  that  was  modified  is 
/opt/ixsadsk/src/microace/project/Count_8_l_2.  The  only  modifications  that  were  made 
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to  the  project  count_8_l_2  was  to  the  Count.uc  file,  which  defines  the  processing 
function  being  call  in  the  Count  IngressDispatch.uc,  the  ingress  dispatch  loop  file  of  the 
project. 

Below  is  a  line  by  line  narrative  of  the  modified  code  for  Count.uc,  as  provided  in 
Appendix  A. 

1 .  The  application  Count  defines  constants  that  are  to  be  used  in  the  program. 

2.  It  declares  both  local  and  global  registers.  Global  registers  are  accessible 
to  other  Microblocks  enabling  inter-process  communications.  After  this  is 
completed  a  call  is  made  to  include  the  other  functions. 

3.  Initializes  each  Microblock  in  the  Microblock  group. 

4.  Starts  the  packet  filter  function  (the  Filter()  macro  is  a  modification  of  the 
original  Counter()  macro). 

5.  Checks  for  packets  passed  down  from  the  core  Micro  ACEs.  This  is  done 
by  polling  the  core  processor  to  queue  the  Microengine. 

6.  Checks  if  a  packet  was  retrieved  from  the  queue. 

7.  Returns  the  data  pointer  for  the  packet’s  buffer  and  handles  returns:  The 
data  pointer  (into  SDRAM). 

8.  Addition  of  the  pointer  to  the  packet  data  in  SDRAM. 

9.  Directs  the  pointer  to  the  correct  location  to  obtain  the  necessary  type  of 
packet. 

10.  Allocates  four  continuous  registers  and  treats  them  as  a  one  single  string. 

11.  Takes  the  numeric  value  that  is  in  the  field  and  places  it  into  the  variable 
type. 

12.  Checks  to  see  if  it  is  an  IP  packet  or  another  type  of  packet. 

13.  Branches  for  IP  packet  and  other  types  of  packets 

a.  IP  packet 

i.  Allocates  eight  new  registers  in  SDRAM  to  store  the  packet 
while  working  on  the  IP  header 

ii.  Reads  the  IP  header 

iii.  Assigns  a  variable  to  store  the  numerical  value  of  the 
protocol  type  in. 
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iv.  Reads  the  value  of  protocol  type  and  stores  it. 

V.  The  variable  is  read  and  the  loop  branches  depending  on 
the  Value. 

1 .  Value  6  indicates  TCP  and  is  sent  out  port  two 

2.  Value  17  indicates  UDP  and  is  sent  out  port  four 

3.  Any  other  value  is  sent  out  port  one  as  an  exception 
b.  Ethernet  sent  to  port  one. 

E.  COMPILING  AND  RUNNING  CODE 

1,  Compiling  the  Microcode  Source  Files 

The  first  step  is  to  compile  the  Microcode  source  files  using  the  Malefile.win. 
This  can  be  achieved  using  Cygwin  on  the  windows  operating  system.  Cygwin  is  a 
command  line  interface  that  is  used  on  the  windows  machine  to  manipulate  the  files  in 
the  Linux  format. 

From  the  command  line  the  command  echo  is  used  to  ensure  the  $IXROOT  and 
SCONFIG  are  correct,  such  as,  “echo  $IXROOT  and  echo  $CONFIG”.  $IXROOT 
should  be  /opt/ixasdk  and  $CONFIG  should  be  ARM  BE.  If  not,  the  command  export  is 
used  to  correct  them  to  “export  IXROOT=/opt/ixasdk  or  export  CONFIG=ARM_BE”. 

Next  a  change  in  directories  is  needed  to 
$IXROOT/src/microace/aces/tutoriall/ucbuild.  This  is  done  with  the  command  “cd 
$IXROOT/src/microace/aces/tutoriall/ucbuild”. 

Once  the  directory  is  correct  compile  the  Microcode  to  make  the  .uof  files.  The 
command  to  compile  these  sources  is  “make  -f  Makefile.win”. 

Now  getting  these  .uof  file  to  where  the  IXP1200  card  can  read  and  use  them  is 
necessary.  It  may  be  possible  to  use  FTP,  but  I  did  not  have  any  luck  doing  that  and  used 
a  copy  command  on  the  command  line  in  Cygwin,  such  as,  “scp  ,uof 
root@192.168.0.4:/opt/ixasdk/bin/arm-be*” 

2,  Compiling  Core  Component  of  MicroACE 

Another  change  of  directories  is  needed  to 
$IXROOT/src/microace/aces/tutoriall/count_acel  using  the  command  “cd 
$IXROOT/src/microace/aces/tutoriall/count_acel”.  Now  ensure  $IXROOT  is 
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/opt/ixasdk,  $config  is  ARM  BE  and  $IXPSDKROOT  is  c:/ixpl200.  Complete  just  like 
above. 

Next  in  the  command  line  type  the  command  “make”  then  change  directory  to 
$IXROOT/src/microace/projects/Count_8_l 

3.  Running  the  Application 

Reboot  the  host  computer  in  Linux.  Then  Open  a  command  window  on  the  host 
computer  the  IXP1200  card  is  remotely  accessed  from  this  command  window  by  typing 
“cd  /opt/ixasdk/enp-2505/bootixp”,  next  Type  “./bootixp”  to  boot  the  IXP1200.  To  check 
the  status  of  the  IXP1200  to  see  if  it  is  up  and  running  use  the  command  “ifup”  from  the 
same  command  window  that  was  used  above  that  should  be  now  the  command  window 
for  the  IXP1200.  The  command  “ifup”  not  only  relays  the  IP  address,  but  starts  the  port 
mapper  and  the  debugger.  The  StrongARM  of  the  IXP1200  needs  to  know  were  to 
access  its  files  from  the  host  computer  this  maybe  done  by  using  the  terminal  window  of 
the  IXP1200  card.  The  mount  command  is  used  to  achieve  this  by  configure  the 
StrongARM  to  retrieve  its  code  by  entering  the  command,  “mount  -tnfs  <host  IP 
address>:/opt/ixasdk/bin/arm-be  mnt”.  Then  change  to  directory  mnt.  At  this  point  the 
application  is  ready  for  use.  To  start  the  new  project  the  command  is  “./ixstart  <your 
config  file>. 

The  configuration  file  is  what  the  StrongARM  uses,  while  run  from  the  ixstart. 
The  configuration  file  has  all  the  parameters  that  are  needed  to  run  the  project.  These 
parameters  consist  of  were  and  what  .uof  file  are  to  be  loaded  onto  which  Microengine 
for  the  project.  With  in  the  parameters  or  configurations  can  be  changed  things  like  the 
number  of  ports  and  IP  address  that  are  available  to  the  IXP1200  card.  Theoretically  a 
programmer  can  make  simple  changes  to  the  congregation  file  to  modify  the  project  by 
assigning  new  .uof  file  that  are  already  compiled. 
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F.  SUMMARY 

Programming  the  IXP1200  involves  many  eomponents.  The  Windows 
environment  supports  the  Intel’s  Development  Workbeneh  and  allows  the  management 
and  debugging  of  Mieroeode.  The  Linux  environment  allows  the  programming  of  eore 
proeessor  the  StrongARM,  while  providing  an  interfaee  with  hardware.  There  are  many 
variables  involved  to  suoeeed;  hardware  must  be  eonneeted  eorreetly  so  eompiled  c  and 
Mieroeode  exeeutables  ean  be  loaded,  and  the  eonfiguration  file  eorreetly  set  for  the 
program  to  finally  run  on  the  IXP1200  eard.  To  run  the  IXP1200  effeetively  the 
programmer  has  to  eonsider  the  use  of  multiple  threads  running  at  the  same  time  in  order 
to  manage  memory  and  deadloek  that  ean  be  ereated  in  the  environment.  This  ehapter 
presented  the  steps  and  modifieations  needed  to  implement  a  TCP/UDP  filtering  funetion 
ontheIXP1200. 
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IV.  CONCLUSIONS  AND  RECOMMENDATION 


Network  processors  started  as  central  processing  units  using  basic  RAM  and 
ROM  to  store  its  operating  system  and  routing  tables  to  maintain  connections  to  the 
networks.  Over  time  network  processors  have  evolved,  such  as,  Intel’s  newly  developed 
IXP1200  network  processor  card  that  consists  of  multiple  programmable  processors.  It 
contains  two  buses  for  communications,  the  PCI  bus  talks  between  the  host  computer  and 
IXP1200  card  while  the  IX  bus  is  the  link  between  components  on  the  card.  The  card  has 
one  master  processor,  the  StrongARM,  which  supports  six  processors  the  Microengines 
that  run  independently.  All  are  programmable  and  are  able  run  parallel  processing  which 
has  the  ability  to  increase  network  processing  speed  and  be  programmable  for  change. 

The  Developer’s  Workbench  is  the  key  component  of  Intel’s  Software 
Development  Kit  which  features  a  GUI  based  simulator  for  the  Microengines.  Its 
purpose  is  to  test  and  developed  programs  for  the  Microengines  which  contains  pre¬ 
developed,  proven  code  known  as  Active  Computing  Elements  (ACEs).  Because  of 
ACEs  the  IXP1200  is  able  to  run  tasks  in  parallel.  This  is  one  way  it  differs  from  the 
typical  sequential  line  program 

The  IXP1200  card  is  a  very  complex  piece  of  equipment  that  requires  precise, 
detailed  instructions  to  install;  as  well  as  the  process  of  creating  and  changing  preexisting 
programs  to  run  on  the  IXP1200  card.  Tools,  such  as,  the  Developer’s  Workbench 
provided  by  Intel  makes  it  possible  to  take  preexisting  code  and  with  simple 
modifications  produce  good  running  code  for  a  specific  task  by  using  code  reuse.  The 
IXP1200’s  ability  to  reuse  code  worked  quite  well  when  modifying  Intel’s  count  program 
into  a  packet  filter  for  TCP  and  UDP. 

There  were  problems  that  arose  because  of  the  complexity  of  the  IXP1200 
system.  Below  is  a  list  of  problems  that  were  discovered  and  recommendations. 

In  today’s  world  of  security  and  numerous  upgrades  to  operating  systems, 
difficulties  arose  between  the  two  different  operating  systems  in  their  ability  to  talk. 
Intel’s  answer  to  making  the  systems  talk  was  ETP.  In  my  research,  I  was  unable  to 
achieve  this  function  in  the  development  process  and  had  to  come  up  with  other  options 
like  copying  files  from  one  IP  address  to  another  IP  address. 
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The  IXP1200  card  9  pin  serial  connector  uses  COMl  for  communications  to  the 
host  PC,  therefore  it  can  cause  conflicts  with  Windows  mouse.  This  conflict  arose  with 
Windows  2000  which  checks  for  new  hardware  at  startup  and  periodically  thereafter. 
During  this  check,  Windows  assumes  that  the  connection  on  comport  one  is  a  serial 
connection  for  a  mouse.  The  IXP1200  card  uses  COMl  as  its  COM  port  and  if  the 
connection  is  changed  to  COM2  or  another  serial  connection  the  card  will  not  boot 
correctly. 

After  performing  updates  for  Windows  2000,  Cygwin  encountered  errors  when 
starting  the  program  and  would  not  continue  running.  To  correct  this  problem  required 
that  all  of  the  SDK  be  removed  before  reinstalling  Cygwin.  Due  to  the  fact  Windows 
sees  Cygwin  as  part  of  the  SDK;  therefore,  not  allowing  it  to  be  removed  and  reinstalled 
by  itself 

One  should  not  recompile  the  grub- 1-0. src.rpm  provided  by  the  Intel  installation 
disk.  There  is  an  error  in  the  file  that  destroys  the  boot  file  for  Windows  2000,  which 
makes  it  impossible  to  boot  Windows.  If  this  file  was  recompiled,  when  starting 
Windows  the  following  message  would  appear:  “Windows  2000  could  not  start  because 
the  following  file  is  missing  or  corrupt:  <windows  2000  root)\system32\ntoskml.exe. 
Please  re-install  a  copy  of  the  above  file”.  For  this  reason  VMware  cannot  be  installed. 
Further  research  revealed  that  possibly  using  Windows  NT  version  4  vice  Windows  2000 
may  fix  this  problem.  Note:  There  are  many  versions  and  configurations  of  IXP1200  and 
SDK  out  on  the  web  which  adds  to  the  confusion  of  finding  the  answer  to  fix  this 
problem. 

While  installing  Windows  2000  on  top  of  Linux  there’s  a  possibility  of  losing  the 
grub  file,  but  there  is  an  uncomplicated  fix  for  this.  In  Linux  command  window  type 
“grub”,  enter  “root(hd0,I)”,  then  enter  “setup”.  This  will  set  the  grub  fide  back  to  the 
default. 

When  the  kernel  for  Linux  7.2  is  recompiled  to  support  the  IXP1200  it  limits  the 
function  of  the  original  kernel.  Problems  were  encountered  with  mounting  the  A  drive  or 
floppy.  To  solve  this  two  versions  of  Linux  were  ran,  the  original  7.2  and  the  upgraded 
7.2  version  for  IXP1200. 
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There  are  immense  possibilities  for  IXP1200  in  the  future  with  the  ability  of 
parallel  proeessing  and  being  able  to  program  in  a  timely  manner  with  the  use  of  code 
reuse  within  Intel’s  SDK.  The  problem  is  making  people  aware  of  the  IXP1200  and 
developing  a  foundation  of  knowledge  to  perfect  new  beneficial  uses  for  it. 

My  recommendation  is  to  first  create  a  stable  platform  of  computers  or  computer 
lab  for  the  IXP1200  and  then  provide  a  class  for  programming  the  IXP1200.  This  class 
would  expose  more  students  to  IXP1200  thus,  creating  more  interest  in  it  and 
subsequently,  increasing  the  knowledge  base  for  the  IXP1200  card. 

By  creating  this  lab  and  giving  the  students  a  base  at  which  to  start  from  would 
expedite  the  learning  process  and  any  further  research  to  be  done  with  the  IXP1200. 
Only  with  increased  exposure  will  the  true  potential  for  the  IXP1200  card  be  reached. 
The  IXP1200  possess  the  ability  to  be  programmable.  Along  with  its  six  Microengines’ 
ability  to  each  run  four  continuous  threads  in  a  parallel  processing  nature,  the  possibilities 
are  unlimited  with  the  versatility  and  the  speed  it  can  provide. 
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APPENDIX  A.  TCP  AND  UDP  PACKET  FILTER 


#ifndef  _Filt_ 

#define  _Filt_ 

#include  "stdmac.uc" 

#include  "field.uc" 

#include  "xbuf.uc" 

#include  "endian.uc" 

#include  "ip.uc" 

#include  "Buf_h.uc" 

#include  "CountControlBlock.h" 
#include  "Count-internal  h.uc" 

#include  "Debug_h.uc" 


7/888888888888888888888888888888888888888888888888888888888888888 
//  #include  "FiltImportVars.h"  is  the  header  file  that  has  the  variables  for  filter. 
7/888888888888888888888888888888888888888888888888888888888888888 
#inelude  "FiltImportVars.h" 

#maoro  Filter_Init() 

#endm 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Filter  is  the  name  of  the  maero  being  ealled  from  the  dispateh  loop 
7/8888888888888888888888888888888888888888888888888888888888888888 
#maoro  Filter() 


7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Deseription: 

7/  .loeal  assigns  loeal  variables  to  be  used  in  this  dispateh  Loop. 
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7/8888888888888888888888888888888888888888888888888888888888888888 
.local  input_port  exceptioncode  statsaddr  data_ptr  dataoffset  type 
expectedtype 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

7/  This  macro  is  used  to  obtain  the  port  on  which  the  packet  being  processed 
7/  was  received.  Valid  range  is  0  to  255. 

7/8888888888888888888888888888888888888888888888888888888888888888 

DL_GetInputPort[input_port] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Assigns  a  place  in  memory  for  stats  addr  to  track  the  number  of  packets 
7/8888888888888888888888888888888888888888888888888888888888888888 

immed32[stats_addr,  Filt  STATS  BLOCK] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Increments  stats  addr  for  each  packet  that  is  taking  in  from  the  input  port 
7/8888888888888888888888888888888888888888888888888888888888888888 

Filt_IncrementPacketFilter[stats_addr] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  This  macro  returns  the  data  pointer  for  the  given  buffer  handle  returns: 
//The  data  pointer  (into  sdram) 

7/8888888888888888888888888888888888888888888888888888888888888888 
Buf_GetData(data_ptr,  dl  buffer  handle) 
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7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  This  macro  is  used  for  the  purpose  of  obtaining  the  offset  of  the  packet 
data  from  the  starting  point  of  the  packet  buffer.  This  is  combined  with 
Buf  GetData  to  obtain  the  pointer  to  the  packet  data  in  SDRAM. 
7/8888888888888888888888888888888888888888888888888888888888888888 
DL_GetBufferOffset(data_offset) 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

7/  This  macro  is  used  by  the  alu  to  direct  the  pointer  to  the  correct  location  to 
//  obtain  the  type  of  packet. 

7/8888888888888888888888888888888888888888888888888888888888888888 
alu[data_ptr,  data_ptr,  +,  data  offset,  »3] 
7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  ??? 

7/8888888888888888888888888888888888888888888888888888888888888888 
Debug_Assert(data_offset  &  0x7  ==  0) 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Allocates  four  continuous  registers  and  treats  them  as  a  one  single  string 
7/8888888888888888888888888888888888888888888888888888888888888888 
xbuf_alloc($$12_header,  4) 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

Instruction  which  reads  the  first  two  quad  words  from  SDRAM  starting  at 
data_ptr.  The  destination  is  the  continuous  registers  that  are  allocated. 
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The  ctx_swap  value  is  a  flag  to  the  Microengine  to  swap  this  thread  out 
until  this  memory  request  is  satisfied. 

7/8888888888888888888888888888888888888888888888888888888888888888 
sdram[read,  $$12_header[0],  data_ptr,  0,  2],  ctx_swap 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Instruction  that  takes  the  numeric  value  that  is  in  the  field  and  places  it 
into  the  variable  type. 

7/8888888888888888888888888888888888888888888888888888888888888888 
xbuf_extract(type,  $$12_header,  12,  0,  2) 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Instruction  that  places  a  variable  with  a  constant  value  in  the  register 
expectedtype. 

7/8888888888888888888888888888888888888888888888888888888888888888 
immed32(expected_type,  ETH_TYPE_IP) 

7/888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Instruction  that  frees  up  the  register  $$I2_header 
7/8888888888888888888888888888888888888888888888888888888888888888 
xbuf_free  [  $  $12_header] 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Instruction  that  uses  the  AEU  subtract  type  from  expected  type  answer 
places  is  placed  in  br! 

7/8888888888888888888888888888888888888888888888888888888888888888 
alu[— ,  type,  -,  expected_type] 
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7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Instruction  checks  to  see  if  it  is  an  IP  or  Ethernet.  A  0  indicates  a  Ethernet 
packet  which  makes  the  program  jump  to  the  label  mepass. 
7/8888888888888888888888888888888888888888888888888888888888888888 
hr  !=0  [mepass#] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

//  Instruction  allocates  eight  new  registers  in  SDRAM  ($$ip_header)  to  be 
used  to  work  on  the  IP  header 

7/8888888888888888888888888888888888888888888888888888888888888888 
xbuf_alloc($$ip_header,  8) 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Instruction  reads  the  header  of  the  IP  packet  into  the  register  $$ip_header. 
The  sig_done  value  is  a  flag  to  the  Microengine  to  swap  this  thread  out  until  this 
memory  request  is  satisfied. 

7/8888888888888888888888888888888888888888888888888888888888888888 
sdram[read,  $$ip_header[0],  data_ptr  ,  1,4],  sig  done 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

7/  Instruction  wait  for  the  read  of  the  IP  header. 

7/8888888888888888888888888888888888888888888888888888888888888888 

ctx_arb[sdram] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 
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//  Assigns  a  variable  proto 

7/8888888888888888888888888888888888888888888888888888888888888888 
•local  proto 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Instruction  that  takes  the  numeric  value  that  is  in  the  packet  type  field  and 
places  it  into  the  variable  proto. 

7/8888888888888888888888888888888888888888888888888888888888888888 
xbuf_extract(proto,  $$ip_header,  15,  0,  1) 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Instruction  assigns  the  value  of  17  to  UDP  and  6  to  TCP 
7/8888888888888888888888888888888888888888888888888888888888888888 
immed32(UDP,0xl7) 
immed32(TCP,0x6) 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Instruction  checks  to  see  if  proto  is  TCP  or  UDP  and  then  jumps  to  the 
appropriate  place. 

7/8888888888888888888888888888888888888888888888888888888888888888 
if  (proto  ==  TCP) 
br[TCP#] 

elif  (proto  ==  UDP) 

br[UDP#] 

else 

br[exception#] 

#endif 
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.endlocal 


7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Label  for  TCP  packet 

7/8888888888888888888888888888888888888888888888888888888888888888 

TCP# 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Sets  the  out  going  port  to  port  two 

7/8888888888888888888888888888888888888888888888888888888888888888 

DL_SetOutputPort[2] 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

7/  Resets  port  two  to  be  used  after  the  packet  is  sent. 
7/8888888888888888888888888888888888888888888888888888888888888888 
immed[dl_next_block,  1  ] 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

7/  End  of  the  jump  or  br 

7/8888888888888888888888888888888888888888888888888888888888888888 

br[end#] 


7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Label  for  UDP  packet 

7/8888888888888888888888888888888888888888888888888888888888888888 

UDP# 
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7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Sets  the  out  going  port  to  port  four. 

7/8888888888888888888888888888888888888888888888888888888888888888 

DL_SetOutputPort[4] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Resets  the  port  four  to  be  used  after  the  packet  is  sent. 
7/8888888888888888888888888888888888888888888888888888888888888888 
immed[dl_next_block,  1  ] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  End  of  the  jump  or  hr 

7/8888888888888888888888888888888888888888888888888888888888888888 

br[end#] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 

7/  Labels  mepass  for  the  first  check  if  ethernet  packets  sent  packets  out  port 
one 

7/8888888888888888888888888888888888888888888888888888888888888888 

mepass#: 

immed[dl_next_block,  1] 

DL_SetQueueNum[input_port] 

br[end#] 

7/8888888888888888888888888888888888888888888888888888888888888888 
7/  Description: 
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//  Label  for  exception  to  handle  everything  that  is  not  covered  by  the  other 
checks  then  sends  in  out  port  one 

7/8888888888888888888888888888888888888888888888888888888888888888 

exception#: 

immed[dl_next_block,  IX  EXCEPTION] 
immed[exception_code,  5] 

DE_SetExceptionCode[exception_code] 

DE_SetQueueNum[input_port] 

7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  Eabel  for  end  that  frees  up  $$ip_header  and  restarts  the  loop  port  one 

7/8888888888888888888888888888888888888888888888888888888888888888 

end#: 


xbuf_free[$$ip_header] 

.endlocal 


7/8888888888888888888888888888888888888888888888888888888888888888 
//  Description: 

//  End  of  the  macro 

7/8888888888888888888888888888888888888888888888888888888888888888 

#endm 


#endif 
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APPENDIX  B.  INSTALLATION  OF  HARDWARE  AND 

SOFTWARE 

A,  SYSTEM  REQUIREMENTS 

This  setup  is  for  a  dual  boot  system  operating  on  Red  Hat  7.2  and  Windows  2000. 
This  development  environment  is  a  combination  of  Windows  2000  and  Linux  platform  or 
Cygwin  for  Linux  environment  on  the  Windows  2000  operating  system  that  provides  the 
following  list  of  tools: 

1.  Microengine  tool  chain  contains  an  embedded  Linux  version  of  the  IXP1200 
Microengine  Development  Environment,  running  on  Windows  2000.  The 
IXP1200  Card  has  to  have  the  modified  version  of  Linux  7.2  to  run,  but 
Microengine  Development  Environment  allows  the  user  to  simulate  code  and 
debug  before  running  the  code  on  the  IXP1200  card  in  the  Einux  operating 
system. 

2.  StrongARM  tool  chain  is  a  GNU/CPP  cross-hosted  tool  chain  that  can  be 
called  from  a  command  shell  or  through  a  Embedded  Linux  IDE,  which 
allows  the  user  to  develop  and  debug  code  running  on  the  StrongARM  on  the 
IXP1200. 

3.  Omni  NES  Sever  makes  directories  located  on  Windows  platform  visible  to 
application  code  running  on  the  StrongARM. 

4.  Einux  IDE  supports  application  development,  kernel  debugging  and  device 
driver  development. 

The  Einux  side  of  the  system  needs  Red  Hat  7.2  to  be  modified  for  a  host 
operating  system  for  the  IXP1200  board.  Earlier  and  later  versions  of  Red  Hat  will  not 
support  the  IXP1200  card. 


B,  INSTALLATION  OF  WINDOWS  2000 

1.  Begin  by  formatting  half  of  the  hard  drive  space  for  the  windows  operating 
system  then  install  Windows  2000. 
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2.  From  windows  control  Panel  choose  Users  and  Passwords 


Cameras 


Users  and 
Passwords 

i  I II  .-.1  -  -  ^ 

Figure  12.  User  and  Passwords 

2.1  Add  the  user  ixa  and  remember  the  password 
3.  Log  off  to  install  Linux 

C.  INSTALLATION  OF  RED  HAT  7.2  FROM  CD  ROM 

1 .  Acquiring  Red  Hat  7.2 

1.1.  This  can  be  down  loaded  from  a  web  sight  at  URL 
http://six.retes.hu/download/redhat/.  The  fdes  must  be  burned  to  a  disk  so  that 
they  can  be  used  as  a  boot-disk  during  the  installation  process. 

Note:  The  Windows  operating  system  must  be  installed  first  in  order  to  use 
the  grub  function. 

2.  Insert  the  number  one  disk  into  the  CD  drive. 

Note:  The  boot  directory  in  the  BIOS  may  need  to  be  reset.  To  get  to  the 
BIOS  there  will  be  an  option  as  the  computer  boots  up.  (CTRL-ESC,  F1,ALT- 
Tab) 

3.  Select  the  language  of  the  user  of  the  computer 

3.1.  Click  Next 

4.  Select  model  of  keyboard  to  be  used 

4.1.  Click  Next 
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5.  Select  model  of  mouse  to  be  used 

5.1.  Click  Next 

6.  A  welcome  window  will  appear 

6.1.  Click  Next 

7.  Select  Installation  Type  “Custom” 

7.1.  Click  Next 

8.  Choose  “Manually  Partition  with  Disk  Druid”  to  partition  the  hard  drive 

8.1.  Click  Next 

9.  Click  on  Free  space 

9.1.  Click  on  New 

10.  Click  on  Mount  Point  arrow  and  select  “/boot” 

1 1 .  Click  on  File  system  Type  arrow  and  select  “ext2” 

12.  Click  on  Size  (MB)  block  and  enter  “50” 

1 3 .  Select  Fixed  Size 

13.1.  Click  OK 

13.2.  Note:  Warning  click  “add  anyway” 

13.3.  Click  on  New 

14.  Click  on  File  system  Type  arrow  and  select  “swap” 

15.  Click  on  Size  (MB)  block  and  enter  “512” 

16.  Select  Fixed  Size 
16.1.  Click  OK 

17.  Click  on  New 

18.  Click  on  Mount  Point  arrow  and  select  “/” 

19.  Click  on  File  system  Type  arrow  and  select  “ext2” 
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20.  Click  on  Size  (MB)  block  and  enter  “4096” 

2 1 .  Select  Fixed  Size 

21.1.  Click  OK 

22.  Click  on  New 

23.  Click  on  Mount  Point  arrow  and  select  “/home” 

24.  Click  on  File  system  Type  arrow  and  select  “ext2” 

25.  Click  on  Size  (MB)  block  and  enter  “50” 

26.  Select  “Fill  to  Maximum  allowable  size” 

26.1.  Click  OK 

26.2.  Click  Next 

27.  Select  use  GRUB  as  the  boot  loader 

28.  Select  install  Boot  Loader  record  on  “/dev/had  Master  Boot  Record  (MBR) 

29.  Enter  “Windows  2000”  for  Boot  label  box 

29.1.  Note:  This  label  is  for  the  operating  systems  in  the  GRUB  boot  loader. 
There  is  also  the  option  to  pick  a  default  operating  system  by  clicking  the  box  to 
the  left  of  it  at  the  bottom  of  the  screen. 

29.1.1.  Click  Next 

30.  No  password  is  needed  on  the  GRUB 

30.1.  Click  Next 

3 1 .  Do  not  configure  the  Network 

31.1.  Click  Next 

32.  Select  No  firewall 

32.1.  Click  Next 

33.  Select  Language  support 

33.1.  Click  Next 
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34.  Select  Time  Zone 


34.1.  Click  Next 

35.  Enter  root  password  twice 

36.  Add  a  user  “ixa 

36.1.  Click  “Add” 

36.1.1.  Enter  User  “ixa” 

36. 1 .2.  Enter  Password  “  The  same  one  from  Windows  “ 

36. 1 .3.  Enter  Confirm  Password 

36.1.3.1.  Click  “OK” 

Note:  Under  Account  Names  your  user  should  appear. 

36.1.4.  Click  Next 

37.  Authentication  Configuration 

37.1.  Click  Next 

38.  Package  Group  Selection  ensure  the  selection  at  least: 

38.1.  NSE  Pile  Server 

38.2.  Software  Development 

38.3.  Kernel  Development 

38.4.  Windows  Compatibility  /  Interoperability 

Note:  Remember  the  size  of  the  installation  on  the  bottom  of  the  screen 

38.4.1.  Click  Next 

39.  SelectVideoC onfiguration 

39.1.  Click  Next 

40.  This  is  the  point  at  which  the  installation  will  begin. 

40.1.  Click  Next 
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41.  Insert  Disk  two 


41.1.  Click  OK 

42.  Select  box  to  make  a  boot  disk 

42.1.  Click  Next 

43.  Select  Monitor 

43.1.  Click  Next 

44.  Select  Color  Depth  “High  Color  (16  Bit)”,  Screen  Resolution  “1024x768”, 
“Graphical” 

44.1.  Click  Next 

D,  UPGRADING  RED  HAT  LINUX  KERNEL 

1 .  Log  into  Linux  as  root 

2.  Insert  CD  “IXA  EDU 

3.  Using  a  command  window  type  “cd  /mnt/cdrom/Host_Linux_upgrade” 

4.  Using  a  command  window  type  “rpm  -recompile  linux-24-17src.rpm” 

5.  Reboot  to  check  if  system  is  intact 

6.  Edit  the  ^oot/grub/grub.conf 

Replace  with  sample  below 

#  grub.conf  generated  by  anaconda 

#  Note:  It  is  not  required  that  grub  be  rerun  after  making  changes 
to  #  this  file 

#  NOTICE:  There  is  a  /boot  partition.  This  means  that 

#  all  kernel  and  initrd  paths  are  relative  to  /boot/,  eg. 

#  root(hd0,l) 

#  kernel  /vmlinuz -version  ro  root=/dev/hda3 

#  initrd  /initrd-version.img 
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#boot=/dev/hda 


default=0 

timeout=10 

splashimage=(hdO,  1  )/grub/splash.xpm.gz 
title  Red  Hat  Linux  (2.4.7-10) 
root  (hd0,l) 

kernel  /vmlinuz-2.4.7-10  ro  root=/dev/hda3 

title  Red  Hat  Linux  (2.4.17) 
root (hd0,l) 

kernel /vmlinuz-2.4.17  ro  root=/dev/hda3 

E.  INSTALL  IXA  SDK  WORKBENCH  FOR  WINDOWS 

1.  Insert  “Intel  Internet  Exehange  Arehiteeture  Software  Development  Kit  CD  1 
Version  2.01  Volume  II  CD  I” 

2.  Run“cd;\workbeneh\setup” 


Figure  13.  Setup  leon 

3.  There  will  appear  an  information  label  about  IXP1200Portmapper  and  Windows 
NT 
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Information 


2<i 


If  you  are  running  Windows  NT  and  are  planning  to  install 
over  an  older  release  version^  please  make  sure  to 
STOP  the  IXP1200  Portmapper  service  located  in  the  Control 
Panel  -  Services  Group  before  continuing.  Not  doing  so 
will  result  in  an  installation  error. 


Figure  14.  Information  Window 

3.1.  Click  OK 


4.  Use  Alt-Tab  to  close  all  other  program 


Figure  15.  Information  Window 

4.1.  Click  Next 

5.  License  Agreement 


.»:l 


Figure  16. 


License  Agreement 


5.1.  Click  Yes 

6.  Setup  location  should  be  Drive  “c;\IXP1200 

Figure  17.  Information  on  Path 

6.1.  Click  Next 

7.  Select  all  components  to  install 
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Figure  18.  Select  Development  Kit  Components 

7.1.  Click  Next 


8.  Select  program  folder  to  place  the  startup  icons  in 


Select  Program  Folder 


Setup  will  add  piogram  icons  to  the  Program  Folder  isted  below. 
Yoj  may  type  a  new  folder  name,  or  select  one  from  the  existing 
Folders  list.  Click  Next  to  continue. 


Program  Folders: 


Existing  Folders: 


<  Back  I  Next  >  |  Cancel  | 


Figure  19.  Select  Program  Folder 

8.1.  Click  Next 

9.  Install  IXP1200  PortMapper  service 


Question 


The  IXP1200  PortMapper  is  required  when  interfacing  the  IXP1200 
Transactor  to  the  Remote  Foreign  model  or  Debugging  IXP1200 
Hardware. 

Do  you  want  to  Install  the  IXP1200  Portmapper  service? 


No 


Figure  20.  Question 

9.1.  Click  Yes 


The  installation  is  about  to  install  IXP12CI0  Portmapper  Service. 
If  you  choose  to  install  this  service  please  make  sure  to  disable 
any  other  portmapper  services.  These  services  can  be  found 
under  Control  Panel  Services,  Failure  to  do  so  can  result  in 
unpredictable  resultsi 
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Figure  21. 


Information 


9.2.  Click  OK 

10.  There  will  be  a  prompt  for  a  key 


Figure  22.  Question 

10.1.  Click  Yes 


Figure  23.  Enter  Password 

10.2.  Click  Next 


Figure  24.  Question 

10.3.  Click  No 


1 1 .  Install  Adobe  Acrobat  Reader 


j<) 


Vou  will  need  to  install  Adobe  Acrobat  reader  In  order 
to  view  the  IXP1200  documentation.  The  Acrobat  reader 
installation  executable  is  supplied  on  the  IXP1200  Network 
Processor  CD  or  can  be  downloaded  From  the  adobe  website^ 
http://www.adobe.com/products/acrobat/readstep.html 


F igure  2  5 .  Information 

11.1.  Click  OK 
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12.  Workbench  Installation  Complete 


Figure  26.  Information 

12.1.  Click  OK 
F.  CYGWIN  SETUP 

1 .  Install  Cygwin 


Figure  27.  Cygwin  Install 

1.1.  Click  Next 

2.  Cygwin  Install  from  Local  Directory 


Figure  28.  Setup  Options 

2.1.  Click  Next 

3.  Local  Package  Directory 


Figure  29.  Directory  Location  of  Cygwin 

3.1.  Click  Next 
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4.  Setup  Configurations 


Figure  30.  Setup  User  Options 

4.1.  Select  Text  File  Type:  Unix 

4.2.  Select  Install  for:  all 

4.3.  Click  Next 


5.  Select  Packages  to  Install 


x| 


Select  packages  to  install 

Prev 

Curt  I  Exd  I  Full/Parl 

Current  New 

Src? 

Package  ^ 

O  Skip 

■Vci 

IX'^.SDK 

O  Skip 

iVq 

IXii,_armbe_loolchain  — 

O  Skip 

r^a 

IXii,_bincomps 

^  Skip 

nja 

l><A_executive 

0  20010129 

□ 

ash 

0  2.13 

□ 

autoconf 

01-4-3 

□ 

automake 

O  2.04-7a 

□ 

bash 

O  20001221-1 

□ 

binutiis 

01.28-1 

n 

bison 

0  0.0 

□ 

byacc 

O1.0-1-B 

□ 

bzip2 

^  1  n 

^  =  click  to  choose  action,  (p)  =  previous  version,  (x)  =  experimental 


Figure  3 1 .  Component  Options 

5.1.  Click  fcs  to  skip  the  package 

5.2.  Skip  IXA  SDK 

5.3.  Skip  IXA  ambe  toolchain 

5.4.  Skip  lXA_b incomps 

5.5.  Skip  lXA_executive 

5.6.  Click  Next 
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6.  Short  Cuts 


Figure  32.  Icon  Options 

6.1.  Click  Next 


7.  Installation  Complete 


Figure  33.  Installation  Complete 


55 


G.  INSTALLING  OF  IXP1200  CARD 

1 .  Inspect  the  card  for  cracks  or  damage 


Figure  34.  IXP1200  Card  Inspection 


2.  Remove  two  expansion  slot  plate  covers 


Card  slot  for  ENP-2505 


Mother  Board 


Figure  35. 

3.  Install  the  three  pin  eonnector  for  the  serial  cable 


Figure  36.  IXP1200  Three  Pin  Cable  Connector 


4.  Install  ENP-2505  card  in  the  open  slot 
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Card  in  the  PC 


Figure  37.  IXP1200  Card  Installed 


5.  Install  serial  nine  pin  cable  in  the  back  of  the  PC 


Serial  cable  on  the  back  of  the  PC 


Figure  38. 


Connection  of  Serial  Cable 


H.  INSTALLING  LINUX  STRONGARM  DEVELOPMENT 

I .  Log  into  Linux  as  root 

2.  Insert  CD  disk  1  “Intel  Internet  Exchange  Architecture  Software  Development  Kit 
CD  1  Version  2.01  Volume  II  CD  I” 

3 .  Open  a  command  window 

4.  Type  “cd  /mnt/cdrom/rpms” 

4.1.  Enter 

5.  Type  “rpm  -i  ixa.sdk-2.0LD-fcs.i386/.rpm” 

5.1.  Enter 

6.  Type  “rpm  -i  ixa.executive-2.0LD-fcs.i386.rpm” 

6.1.  Enter 

7.  Type  “rpm  -i  armbe-v4b-fcs.i386.rpm” 

7.1.  Enter 

8.  Type  “rpm  -i  ixa.binaries-2.0LD-fcs.i386.rpm” 

8.1.  Enter 

9.  Modify/ect/profile  to  make  a  path  and  environment  variables  permanent.  To  obtain 
access  to  the  GNU  tool  chain,  IXA-specific  utilities  and  compilers  the  file 
“/etc/profile”  must  be  modified 

10.  Open  “/etc/profile” 

10.1.  Replace  / etc/profile  with  text  below 

#  /etc/profile 

#  System  wide  environment  and  startup  programs,  for  login  setup 

#  Eunctions  and  aliases  go  in  /etc/bashrc 


#  Path  manipulation 
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if  [  'id  -u'  =  0  ]  &&  !  echo  $PATH  |  /bin/grep  -q  "/shin"  ;  then 
PATH=/sbin:$PATH 
fi 

if  [  'id  -u'  =  0  ]  &&  !  echo  $PATH  |  /bin/grep  -q  "/usr/sbin"  ;  then 
P  ATH=/usr/sbin:  $P  ATH 
fi 

if  [  'id  -u'  =  0  ]  &&  !  echo  $PATH  |  /bin/grep  -q  "/usr/local/sbin"  ; 
then 

PATH=/usr/local/sbin;$PATH 

fi 

if !  echo  $PATH  |  /bin/grep  -q  "/usr/Xl  lR6/bin"  ;  then 
PATH="$PATH:/usr/Xl  lR6/bin" 
fi 

#  No  core  files  by  default 
ulimit  -S  -c  0  >  /dev/null  2>&1 
USER='id  -un' 

LOGNAME=$USER 

MAIE="/var/spool/mail/$ElSER" 

HOSTNAME='/b  in/hostname' 

HISTSIZE=1000 

if  [  -z  "SINPUTRC"  -a  !  -f  "$HOME/.inputrc"  ];  then 
1NPUTRC=/ etc/ inputrc 
fi 

#  IXA  SDK  path  setting 


60 


if !  echo  $PATH  |  /bin/grep  -q  "/usr/local/armbe/bin"  ;  then 
PATH=  "$PATH:/usr/local/armbe/bin" 
fi 

if  !  echo  $PATH  |  /bin/grep  -q  "/opt/ixasdk/bin"  ;  then 
fi 

IXROOT=7opt/ixasdk" 

CONFIG="ARM_BE" 

export  USER  EOGNAME  MAIL  HOSTNAME  HISTSIZE 
INPUTRC  IXROOT  CONEIG 

for  i  in  /etc/profile.d/*.sh  ;  do 

if  [  -r  $i  ];  then 

.  $i 

fi 

done 
unset  I 

I.  ENP-2505  SOFTWARE  INSTALLATION 

1 .  Log  onto  Linux  as  root 

2.  Insert  CD  “IXA  Education  Workstation” 

3.  Open  command  window 

3.1.  Type  “cd /mnt/cdrom/ENP_2505_Driver 

3.2.  Type  “rpm -recompile  boot_drv-2.0.-I.src.rpm 

4.  Reboot  to  Linux 

J.  BOOTING  UP  IXP1200  CARD 

1 .  Open  command  window 
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1.1.  Type  “cd /opt/ixasdk/enp-2505/bootixp 

1.2.  Type  “.^ootixp 

2.  Check  the  Card  with  a  ping  command 

2.1.  Open  another  command  window 

2.2.  Type  “ping  192.168.0.4” 
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